Backup Procedures
This subsection covers
the backup procedures for BizTalk applications; however, a BizTalk
application is usually just one part of an overall solution that
includes other applications servers, and databases. In general, backup
of an application solution that includes BizTalk requires the following
general procedures:
Back up application code, artifacts, documentation.
Back up server configuration documentation.
Back up BizTalk servers and BizTalk Group databases.
Back up related non-BizTalk databases.
Steps and procedures for
backing up the first two items listed are outside the scope of this article ; however in general, application code, artifacts, code
documentation, and server configuration documentation should be kept in a
source code control system that is backed up automatically with
rotating backup sets maintained at an offsite location.
The following
subsections focus on the last two items listed including backup
procedures for BizTalk runtime servers and for the BizTalk Group.
BizTalk Servers
The servers where
BizTalk is installed and configured should be backed up using your
corporate standards for server backup. In addition, the config.xml file
used to configure each server should be backed up along with
documentation on what host instances, receive ports, and send ports are
installed on the server. This information can be stored in your source
code control system as solution artifacts. Essentially the procedures
used to perform the following steps must be in a format that
administrators can use to perform a restore or disaster recovery vent:
BizTalk installation:
Document what features/service pack/hotfixes are installed on the
BizTalk runtime server. Document what other products such as SharePoint,
IIS, or third-party adapters are installed.
BizTalk configuration:
Back up the config.xml that was used to configure the server. This file
can be reused to configure the server with minor edits depending on
whether the BizTalk Windows server name changed or the SQL instance
location of the databases has changed.
Master secret:
This is an extremely important backup item. Without the master secret, a BizTalk Group cannot be
restored. The master secret is encrypted and stored in the registry of
the master secret server. It is required in order to access the
credential (SSOdb) database.
BizTalk application configuration: Document host instances, receive ports, send ports, and of course versions of BizTalk application binaries.
Maintaining
the preceding documentation is the minimum requirement necessary to
restore the BizTalk runtime servers. It is recommended to automate
installation, configuration, and application deployment as much as
possible to support normal operations as well as to provide an automated
method to restore the BizTalk runtime servers.
The next subsection covers procedures for backing up the master secret.
The Master Secret
BizTalk Server 2006
includes a new Microsoft Management Console (MMC) snap-in for managing
Enterprise SSO and the master secret, as shown in Figure 1. To launch the SSO Administration tool, go to Start => All Programs =>Microsoft Enterprise Single Sign-On => SSO Administration. To back up the master secret, right-click the System node and select Backup Secret within the GUI.
Clicking Backup Secret displays the dialog box shown in Figure 2,
where you enter a location for the backup file, a password, and
optionally a password reminder. This file should be removed from the
server and stored in a safe place such as a source control system
locally as well as at an offsite location.
The Enterprise SSO
tools SSOManage.exe and SSOConfig.exe are still available in the
C:\Program Files\Common Files\Enterprise Single Sign-On directory to
support scripting, so the master secret can be backed up using the
command-line tool SSOConfig.exe with the -backupSecret switch as well.
Next, we cover procedures for backing up the BizTalk Group.
BizTalk Group
This subsection
covers backup procedures for the BizTalk Group, which consists of a set
of databases created by BizTalk Server 2006 during configuration. All of
the normal requirements when performing SQL backups apply: allocating
sufficient storage space where backup files are stored, copying backup
files to an offsite location, testing restore files on a regular basis
such as monthly, etc. Another consideration is to ensure backup devices
and media are secure to protect business-sensitive data.
NOTE
BizTalk Server
includes a SQL Server role named BTS_BACKUP_USERS so that BizTalk
databases can be backed up without requiring System Administrator
permissions within SQL Server, except for the primary server controlling
the backup process.
If not done already,
configure the Backup BizTalk Server SQL Agent job following the
instructions in the earlier subsection titled "Configuring the Backup
BizTalk Server SQL Agent Job." The Backup BizTalk Server SQL Agent job
backs up the following databases:
BizTalk Configuration (BizTalkMgmtDb)
BizTalk Messagebox (BizTalkMsgBoxDb)
BizTalk Tracking (BizTalkDTADb)
Rule Engine (BizTalkRuleEngineDb)
BAM Primary Import (BAMPrimaryImport)
Trading Partner Management (TPM)
HWS Administration (BizTalkHWSDb)
BizTalk EDI (BizTalkEDIdb)
Credential Database (SSOdb)
You must also back up the
following BizTalk Group databases, which are not part of the Backup
BizTalk Server SQL Agent job because they do not participate in DTC
transactions:
These databases can be
backed up using normal SQL Server backup procedures because they do not
participate in distributed transactions; however, these databases
require special consideration, described in the next subsection, if BAM
is configured with BM.exe and used as part of a BizTalk solution.
BizTalk Server 2006
includes a table named adm_OtherBackupDatabases in the BizTalk
Management database (BizTalkMgmtDb). Other application databases that
participate in DTC transactions (i.e., accessed within an atomic scope
in an orchestration) should be added to adm_OtherBackupDatabases to
remain transactionally consistent with the BizTalk databases. Table 2 lists the column names.
Table 2 Columns in the adm_OtherBackupDatabases Table
| Field Name | Value |
|---|
| DefaultDatabaseName | The alias for the database. Can be the same as the database name or the application name. |
| DatabaseName | The actual name of the database. |
| ServerName | The name of the SQL Server instance hosting the database. |
| BTSServerName | Name of a BizTalk server. Not used, but required. |
Databases added to the
adm_OtherBackupDatabases table will automatically be backed up by the
Backup BizTalk Server SQL Agent job.
|
You must
add any non-BizTalk custom database that performs distributed
transactions with BizTalk to this table so that the table can be
restored to the same log mark and remain transactionally consistent. For
example, if you have an orchestration that updates a database named
App1 within an atomic scope in BizTalk, the database App1 must be added
to the adm_OtherBackupDatabases table.
|
|
The next step is to add the
necessary schema changes to the databases added to the
adm_OtherBackupDatabases table. Otherwise, the Backup BizTalk Server SQL
Agent job will fail. Browse to the <installation
directory>\Program Files\Microsoft BizTalk Server 2006\ Schema
directory, and then run Backup_Setup_All_Procs.sql and Backup_Setup_All_
Tables.sql in the destination database. This creates the necessary
procedures, tables, and rolesto participate in the Backup BizTalk Server
SQL Agent job and assigns permissions to the stored procedures.
Now let's take a look at backup procedures for the SQL Server Analysis Services databases.
BAM Analysis Services and Supporting Databases
BizTalk leverages
SQL Server Analysis Services for reporting and analysis functionality as
part of the Health and Activity Tracking and Business Activity
Monitoring features. In BizTalk Server 2006, the Tracking Analysis
Server OLAP database is available in BizTalk installations as part of
HAT to support the service metrics and message metrics functionality for
SQL Server 2000 Analysis Services only. The Tracking Analysis Server
database is not supported on SQL Server 2005 Analysis Services and is
not available as an option when configuring the BizTalk Group with a SQL
Server 2005 database back end.
A BizTalk Group
configured with BAM enabled in the BizTalk Configuration Wizard results
in two additional SQL Analysis Services OLAP databases if the Tracking
Analysis Server database is present:
These Analysis Services databases must be backed up following the procedures for backing up SQL Analysis Services databases.
There are two scenarios for backing up BAM SQL Server databases when BAM is enabled through the BizTalk Configuration Wizard:
BAM enabled for the BizTalk Group but not configured
BAM enabled and configured with BM.exe (i.e., the BizTalk solution includes BAM features)
The next two subsections cover these scenarios.
BAM Enabled but Not Configured in a BizTalk Group
Since BAM is not
configured with BM.exe, there are not any BAM-related Data
Transformation Services (DTS) packages present in the solution.
Therefore, the BAM SQL databases can be backed up using regular SQL
Server backup procedures or can be added to the Backup BizTalk Server
SQL Agent job by adding the table to the adm_OtherBackupDatabases table
for convenience. Here is a list of the BAM SQL databases that must be
backed up:
This will ensure that a
full set of databases for the BizTalk Group are maintained. The next
subsection covers backup procedures when BAM is enabled and configured
with BM.exe.
BAM Enabled and Configured in a BizTalk Group
When BAM is enabled
and configured for a BizTalk Group using BM.exe, it results in the
creation of one or more DTS packages that must be backed up in case they
are accidentally deleted as well as duplicated on the disaster recovery
site. Backup procedures for DTS packages are documented in SQL
Server Books Online.
Before backing up the
BAM databases, ensure that neither the BAM cube process nor data
maintenance DTS packages are running when the backup package is
scheduled to run. Ensure consistent schema across all BAM databases by
backing up the BAM databases and DTS packages each time a BAM activity
is deployed and not deployed.
The BAM Analysis and BAM
Star Schema databases should be backed up each time a BAM view is
deployed and undeployed. Follow these procedures when backing up BAM
databases:
Run the Backup BizTalk Server job to back up the BAM Primary Import database as well as the other BizTalk Server databases.
Run the BAM data maintenance DTS package for all activities.
|
Incorporate these steps
into a DTS package, scheduling it to run on a regular basis. To
guarantee data integrity, ensure no other BAM cubing or DTS packages run
when this DTS package is scheduled.
|
|
Back
up the BAM Archive database after the partition is copied into the BAM
Archive database but before the partition is deleted from the BAM
Primary Import database so that a complete set of archived data is
maintained. This can be achieved by modifying the data maintenance DTS
package for each activity to add a step to back up the BAM Archive
database before the last step in the DTS package called End Archiving.
Back up the BAM Archive database, and then the BAM Star Schema database.
Next, we cover backup procedures for Business Activity Services.
BAS Site and Databases
Business Activity Services
is an optional installation option and may not be part of a solution. If
BAS is part of a solution, it requires special backup procedures
because the BAS environment consists of the following:
A web site
hosted in Microsoft Windows SharePoint Services and InfoPath templates.
Windows SharePoint Services and InfoPath provide a common user interface
for all of the services included in BAS.
A Trading Partner Management database. This database stores trading partner data for BAS. It is not a runtime database.
Two
Windows SharePoint Services databases: the Configuration and Content
databases. These databases store the global settings for the WSS server
as well as site content. Perform the following steps to back up the BAS
site and database:
After
BAS is configured, back up all of the changes made to the web
application configuration files and Windows SharePoint Services site
templates so these can be recovered later. There may be modifications in
other places, for example, in client-side JavaScript files if the site
has been customized by the development team. These changes must be
documented and backed up to a source code control system as well.
Ensure the Backup BizTalk Server SQL Agent job is configured since it backs up the Trading Partner Management database.
The next subsection covers steps to back up the Base EDI adapter.
Base EDI Adapter
Additional
backup steps are required in order to completely restore the EDI
adapter. The first step is to back up the DocumentsHome directory. This
directory is located here by default: <root>Documents and
Settings\All Users\Application Data\Microsoft\BizTalk Server 2006\
EDI\Subsystem.
NOTE
Path references
to BizTalk Server 2006 may actually be in the BizTalk Server 2004
directory if an in-place upgrade was performed when BizTalk Server 2006
was installed.
In this
directory are subdirectories and folders containing EDI adapter
settings, sent and received documents in EDI and XML format, log files,
in-flight files, and the compiled engine input file (EIF).
The entire DocumentsHome
directory should be backed up frequently using a file-based
high-capacity backup system. Ideally, the DocumentsHome directory is
mirrored using a robust high-capacity storage technology. This also
allows fast restore time because the system automatically switches to
the mirrored disk when necessary. If disk mirroring is not an option,
the DocumentsHome directory should be backed up very frequently to
minimize data loss.
Depending on legal
requirements with partners, incoming EDI documents can be configured to
be received at an alternate receive location that makes a copy of the
incoming document before sending the document to the EDI receive
location. This provides an additional layer of archive for inbound
documents. Another option is to enable message body tracking on inbound
EDI documents. Legal implications may surround message body tracking
depending on the legal agreements with trading partners. Be sure to
review all legal agreements before enabling message body tracking. Also,
message body tracking greatly increases database growth, which must be
taken into account because of potential performance impact.
Now let's look at backup procedures for DTS packages related to the BizTalk solution.
DTS Packages
All DTS packages that are
part of the solution must be duplicated at the disaster recovery site.
The BizTalk Configuration Wizard does not create any DTS packages.
However, if Business Activity Monitoring is part of the solution and is
configured with the BAM monitoring tool (BM.exe), there will be DTS
packages created that generate/update the OLAP cubes. The DTS packages
have names like the following:
BAM_AN_<ViewName>
BAM_DM_<activity name>
NOTE
There are no DTS packages that require backing up if BAM is not configured using the BM.exe tool.
To back up the DTS packages with SQL Server 2000, follow these steps:
Navigate to the Data Transformation Services folder in SQL Server 2000.
Click Local Packages to see a list of DTS packages for the server.
In the right pane, right-click each package and select Design Package.
In the menu, click Package and then Save As.
Click the drop-down for Location and select Structure Storage File.
Click the button with the caption ... and enter a path/file name.
Click OK to generate the DTS file for the package.
Connect to the destination disaster recovery server using Enterprise Manager.
Expand the target server/instance.
Right-click the Data Transformation Services folder and select Open Package.
Browse to the package exported in the preceding steps and import the package to the target server.
Perform the preceding steps for all DTS packages that are part of the solution.
To back up SSIS packages with SQL Server 2005, follow these steps:
Open SQL Server Management Studio and connect to Integration Services.
Expand the Stored Packages folder in Object Explorer.
Expand the subfolders to locate the package that needs to be exported.
Right-click the package, click Export, select File System, and then browse to a location to save the package.
To back up SQL Server Integration Services packages with SQL Server 2005, follow these steps:
Open SQL Server Management Studio and connect to Integration Services.
Expand the Stored Packages folder in Object Explorer.
Expand the subfolders to locate the package that needs to be exported.
Right-click the package, click Export, select File System, and then browse to a location to save the package.
There may be
additional non-BizTalk DTS packages related to the solution. These DTS
packages must also be duplicated at the disaster recovery site as well.
Backing Up SQL Agent Jobs
BizTalk Server 2006 Log
Shipping will re-create the SQL Agent jobs running in production on the
disaster recovery site; however, it is still a best practice to maintain
backups of the SQL Agent jobs in case they need to be restored outside
of a disaster recovery event. Here are the steps to back up a SQL Agent
job in SQL Server 2000:
Open SQL Server 2000 Enterprise Manager.
Expand the database server/instance.
Expand the Management folder.
Expand SQL Server Agent, and then click Jobs.
In the right pane, right-click each job listed, select All Tasks, and then Generate SQL Script.
Choose a location by clicking the button with the caption ... and enter a file name.
Click OK to generate the script.
Run
the script using SQL Server Query Analyzer on the target disaster
recovery site SQL Server instance where the BizTalk Configuration
database is located.
Go through the preceding steps for each job.
For SQL Server 2005, the steps are similar:
Connect to the database instance using SQL Server Management Studio.
Expand SQL Server Agent and click Jobs.
Right-click each job and select Script Job as => Create To => File.
Enter a file name and click Save.
Go through the preceding steps for each job.
The next subsection covers backup procedures for related non-BizTalk applications and databases.
Related Non-BizTalk Applications and Databases
How related
non-BizTalk application databases are backed up depends on the BizTalk
solution. As mentioned earlier, if an orchestration updates another
database from within an atomic scope that results in a distributed
transaction, the other database must be added to the
adm_OtherBackupDatabases so that it is backed up by the Backup BizTalk
Server SQL Agent job and can be restored to the same log mark as all
other databases that participate in distributed transactions as part of
the solution.
For applications
and databases that do not participate in distributed transactions with
BizTalk but are still part of the overall application solution, these
applications and databases should be backed up following your corporate
standards/guidance. Essentially, the same requirements apply in that the
source code, code documentation, runtime environment, etc., must be
backed up such that the application and database can be restored
successfully. Always practice a restore in a lab environment to confirm
that enough information is available to be successful as well as
automate as much of the process as possible.
Next, we cover restore procedures for a BizTalk solution.
